1. Field of the Invention
The proposed invention relates to exchanges between a terminal and smart card. More particularly, the proposed technique relates to the securing of such exchanges. The proposed technique is aimed more particularly at securing the exchanges between a terminal and an integrated circuit. This integrated circuit can be placed in a smart card that can be read by the terminal. This reading can be done with or without contact, depending on the technology employed, both in the reading terminal and in the integrated circuit.
More specifically, the invention relates to the implementation of hardware and software extensions enabling the protection of the nature of the commands exchanged between a reader and an integrated circuit.
2. Description of the Related Art
2.1 Communications Between a Terminal and an Integrated Circuit as Embedded in a Smart Card
At the applications level, the exchanges between a card reader (hereinafter called a “reader” or “terminal”), and a smart card that is inserted therein are carried out by means of application protocol data units (APDU).
2.1.1. The Basic Protocol
APDUs are commands transmitted by the terminal to the card. APDUs also govern the collection of the responses transmitted by the card to the terminal.
The format of these commands and responses is defined at the applications level by the ISO 7816-4 standard and its appendices A and B. The APDU commands are always activated by the terminal and the card must be constantly listening for APDUs coming from the terminal. In other words, according to the ISO 7816-4 standard, and using terminology of common usage among those skilled in the art, the terminal is in “master” mode while the card is in “slave” mode.
The terminal provides the card with energy supply and a clock signal whose frequency is typically 3.5 MHz. The card and the terminal exchange data through by a serial link, the flow rate of which ranges from 9,600 to 230,400 bauds. The terminal produces a request (APDU) which (in compliance with the transportation protocol T=0) comprises at least 5 bytes (CLA INS P1 P2 P3) and optional bytes (of which the length Lc is specified by the value of the byte P3).
The card reacts by delivering a response message which comprises information bytes (of which the length “Le” is specified by the byte P3) and a status word (SW1 SW2) with a width of two bytes SW1 SW2=9000 notifies the success of an operation. When the length of the response is not known in principle, a status word “61 Le” indicates the length of the response message. Once this parameter is known, the terminal obtains the information by means of the GET RESPONSE (CLA C0 00 00 Le) command, as shall be described in detail further below.
The read and write operations and the invocation of the cryptographic functions are associated with specific APDUs. The information stored in the card is stored in a system of files which includes a root directory (MF Master File), sub-directories (DF Dedicated File) and files (EF Elementary File). Each component is identified by a two-byte number; browsing through this system is done by means of particular APDUs (SELECT FILE, READ BINARY, WRITE BINARY) the details of which go beyond the framework of the present technique.
The security of communication between the card and the terminal is provided by simple or mutual authentication protocols (transported by APDUs) which, in the event of success, authorize access to the files.
The implementation of a card therefore uses a procedure call paradigm implemented (transported) by APDUs generally defined for a specific card operating system. The format of the embedded information is known in principle and classified by a system of 7816 type files.
2.1.2. Transportation of APDU Messages (TPDU)
There are several transport protocols. It is necessary to define rules for example to segment the APDUs into blocks compatible with the maximum size authorized by these protocols. Only rules defined for the protocol T=0 shall not be described in detail here.
The header of a TPDU (T=0) always comprises five bytes (CLA INS P1 P2 P3) instead of four in the case of the APDUs.
Case 1. TPDU=CLA INS P1 P2 P3=00
Case 2. exit order or outgoing order:                Short message (short), CLA INS P1 P2 P3=Le, outgoing order of 1 to 256 (Le=0) bytes. The status SW1=6C SW2=La can indicate the maximum value La supported by the card.        Long message (Extended), n adapted number (Le/256) of short requests CLA INS P1 P2 P3=0 is generated. In the last request, P3 is equal to the remainder modulo 256 of Le. An error-free response is terminated by the status 9000 (last segment of the response) or 61 xx (length P3 of the next request).        
Case 3, incoming order:                Short message (short) CLA INS P1 P3 P3=Lc [Lc bytes]. Incoming order of 1 to 2555 bytes. A status 9000 indicates that the operation has been well executed.        Long message (Extended). A series of commands ENVELLOPE, CLA C2 P1 P2 P3 [P3 bytes 1, . . . , 255] is used to carry out the segmentation of the APDU to be transmitted. The status of the response is 9000 in the event of good execution.        
Case 4, outgoing/incoming order:                Short message (short) CLA INS P1 P2 P3=Lc.[Lc bytes]. A status 61 Le indicates the size of the response. The outgoing command GET_RESPONSE CLA C0 P1 P2 P3=Le is used to read the response message, sized Le.        Long message (Extended). In this case, the commands ENVELLOPE and GET_RESPONSE are used.        
Among the parameters defining the formats of the APDUs, the parameter CLA possesses a special role in the securing of exchanges (Secure Messaging mode). Thus, the parameter CLA is defined for the types of particular cards or by particular manufacturers. 00 is the ISO value, AO for the SIM cards, BC has been used by Bull CP8, FF is reserved for the PTS protocol. The quartet of high significance values is defined by the ISO 7816 standard for the values 0,8,9 and A. In this case, the quartet of low significance values comprises two bits which indicate the use of the Secure Messaging (SM: signature and encryption of APDUs) and the last two bits designate a logic channel number (ranging from 0 to 3). The notion of a logic channel implies the simultaneous use of several applications housed in the card.
2.1.3. Secure Messaging Mode
The purpose of the secured transmission of messages (SM) is to protect a part of the messages sent from and to a card in ensuring two elementary security functions: the authentication of data and the confidentiality of data.
The secured transmission of messages is done by applying one or more security mechanisms. Each security mechanism implements an algorithm, a key, an argument and often an initial piece of data.                The transmission and reception of data fields can be interlaced with the execution of security mechanisms. This specification does not exclude the determining, by sequential analysis, of the mechanisms and security tools which are used to process the remainder of the data fields.        Two or more security mechanisms can use the same algorithm in different embodiments (see ISO/IEC 7816). The present specifications of the fill rules do not exclude such a function.        
This clause defines three types of data objects relating to SM:                plain data objects to transport data in plain-text form;        data objects associated with the security mechanisms, intended for transporting the result of the computations made by the security mechanisms.        auxiliary security data objects, to transport control references and descriptors of responses.        
Without needing to go into the technical details of the implementing of the secured transmission mode of messages, it can be stressed that various mechanisms are implemented. They make it possible to obtain protection of certain data objects travelling between the terminal and the integrated circuit (these are for example data objects for authentication). Other data objects of lower sensitivity are not necessarily protected.
Indeed, the encryption and the signing (or authentication) of the data traditionally serve to secure the data exchanged between the card and the terminal. Thus, a terminal which encrypts and authenticates its APDU commands will protect only transferred data against interceptions and modifications. The commands for their part remain in plain-text form.
The encryption and authentication of data exchanged between the communicating apparatuses come under methods known to those skilled in the art, especially the deployment of public key infrastructures (PKI). A PKI is a set of physical and software components used to manage the life cycle of electronic certificates. These certificates make it possible to carry out cryptographic operations such as encryption and digital signature operations which offer the following guarantees during electronic transactions:                confidentiality: only the legitimate addressee (or the possessor) of a message can have an intelligible view;        authentication: during the transmission of a message or during connection to a system, the identity of the sender or the identity of the user who is connected is known with certainty;        integrity: there is the guarantee that a message sent will not be damaged, accidentally or intentionally;        non-rejection: the author of a message cannot deny what he has done.        
It will be noted that there are techniques to ensure confidentiality, authentication and integrity all at once. These are for example “sign encryption” or “authenticated encryption” methods.
2.2. Drawbacks of the Prior Art.
As we have seen, the secure messaging mode does not ensure the confidentiality of the data or the confidentiality of the commands. Thus, the deployment of SM and a PKI in order to ensure encryption and authentication services is of no help against an attack for inferring information that can be used to infer security by using information provided by the APDU CLA INS P1 P2 P3 headers.
Such attacks can for example be:                The blocking of APDUs identified as being unfavorable to the user (for example blocking the erasure of a file of keys following the stoppage of payment of a subscription. Another example is the blocking of a debit order.)        Conversely, attacks by replay. These attacks consist in replaying an APDU which gives benefit to the user (for example credit from a wallet of monetary units).        Attacks known as “man in the middle” attacks which consist in taking position between the card and the terminal and deflecting communications between the card and the terminal at precise instants.        Reverse design or reverse engineering attacks consisting in spying on the exchanges between the terminal and the card in order to infer the operation of the underlying system and thus compromise intellectual property belonging to the designers of the system. Reverse design attacks can also enable the detection of protocol or transactional software flaws and enable software attacks on the underlying system.        
The use of present-day external cryptographic devices such as present-day smart cards does not provide an answer to these threats because the ISO 7816 protocol enables the attacker to understand what a card does without, all the same, necessarily enabling the attacker to understand the data transmitted between the card and the terminal if the SM (Secure Messaging) mode is used.
As has been seen, if it is assumed that the attacker has total control over the link between the card and terminal and, in addition, has knowledge of the significance of the APDU CLA INS P1 P2 P3 headers exchanged between the card and the terminal, then it becomes impossible to ensure the total confidentiality of the application and/or of the system even if the confidentiality and integrity of the data exchanged remains guaranteed by an SM (Secure Messaging) procedure. These are major drawbacks that have enabled numerous attacks against systems implementing smart cards.